Thanks for taking the time to review this one @tellthemachines 🙇

I don't think there's a way for the post editor to know about the settings of the Post Content block, but it would be useful for things like content size too. I guess it's something to look into.

It's a bit of a tricky one. Within the site editor, you could configure settings on an individual Post Content block for a particular template. That wouldn't apply in all cases, so not sure if that means we can safely ignore that for now.

If the Post Content block is styled via Global Styles and we added the .wp-block-post-content class to the root BlockList, then it gets those global typography styles applied. I have no idea about the consequences of doing that at the moment.

diff --git a/packages/edit-post/src/components/visual-editor/index.js b/packages/edit-post/src/components/visual-editor/index.js
index 0d8614946a..b81c56b8f8 100644
--- a/packages/edit-post/src/components/visual-editor/index.js
+++ b/packages/edit-post/src/components/visual-editor/index.js
@@ -265,7 +265,7 @@ export default function VisualEditor( { styles } ) {
 								className={
 									isTemplateMode
 										? 'wp-site-blocks'
-										: 'is-layout-flow' // Ensure root level blocks receive default/flow blockGap styling rules.
+										: 'is-layout-flow wp-block-post-content' // Ensure root level blocks receive default/flow blockGap styling rules.
 								}
 								__experimentalLayout={ layout }
 							/>

Yeah, it doesn't seem to have negative consequences. I wouldn't expect there to be any styles attached to that block from our side at least. Might there be any scenario in which a theme would attach a style to that classname and not expect it to display in the editor?

In any case, that would only solve half the problem because it's just as likely settings would be changed in the actual block as opposed to global styles, and there might be more than one instance of the block with different settings.

I'm not sure what's best here. Perhaps we just add this in for now and then think of a good way for the post editor to reflect styles from the block 🤷

@WordPress/block-themers Any feedback on the discussions above about styling the post content block?

This reminded me of #38862 I don't know if solving the connection between the post content block and what shows in the post editor should be done on this PR or not, but it's definitely something that needs to be considered at some point.

Perhaps we just add this in for now and then think of a good way for the post editor to reflect styles from the block 🤷

I'm not sure this is a good idea. It will mean that we have discrepancies between the front/back end. I think we need to find a way to render content in the post editor inside a post content block before we can do it.

An example of where there already is a discrepancy between the front/back end is the link color in Twenty Twenty-Three, where all links in the post content block have a color on the front, that is not visible in the block editor.

I see that as more reason to fix the existing issues rather than creating more :)

I submitted this PR a few months ago aimed to fix the fact that style settings from core/post-content block in theme.json are not applied in the editor. It seems to be working fine with most of the style settings but I tried it in conjunction with these changes, and the editor is still failing to display the right font sizes because the properties and class names around font sizing are missing in the BlockList component.

Thanks everyone for the discussion on this 👍

I've rebased this PR to pick up the latest changes from #42270 which from my testing does allow theme.json and global styles for the Post Content block to take effect within the block editor.

Summary:

• If an individual Post Content block for a single post page is configured with block supports, those styles are not applied within the block editor.
• Theme.json and Global Styles are applied correctly now post #42270 as it applies the .wp-block-post-content classname in the block editor.

Options

1. Abandon adopting block supports for the Post Content block:
   • Pro: Doesn't introduce inconsistency between site editor, block editor, and frontend (albeit for a single template?)
   • Con: Decreases design tool consistency across blocks.
   • Con: Doesn't allow for users to override anything set by a theme author via theme.json
   • Con: Doesn't move toward a solution
2. Merge as is:
   • Pro: Given theme.json will style the block, this allows a user to tweak those values via Global Styles.
   • Pro: Allows for individual Post Content blocks to be styled differently to the main single template if added to non-single-post templates
   • Con: Introduces a potentially limited inconsistency between site editor, block editor and the frontend.
   • Con: Requires further follow-up to address inconsistency which might not land before the initial 6.1 feature freeze.

My vote would be for Option 2.

Am I missing anything? What do you all think?